fix: vessel-switch stale camera reattach + docking camera list#3
Closed
jonpepler wants to merge 4 commits into
Closed
fix: vessel-switch stale camera reattach + docking camera list#3jonpepler wants to merge 4 commits into
jonpepler wants to merge 4 commits into
Conversation
…ed tombstone RebuildCameraList tears down and rebuilds every tracked camera on onVesselChange, including ones whose part persists across the switch. That teardown writes no destroyed tombstone (reserved for actual part destruction), so a ring can be deleted and recreated at the same flight_id within one frame with rescan() none the wiser - the sidecar kept its mmap on the unlinked file, and the feed went stale with no way to recover short of restarting the sidecar (kerbcast#2). rescan() now tracks each ring's filesystem identity and reattaches when it changes, reusing the existing attach-driven peer resync path. Also expand the TROUBLESHOOTING.md "Still stuck?" section into a reusable log-collection checklist instead of writing bespoke instructions per issue.
MetadataExt::file_index() is gated behind the unstable windows_by_handle feature (rust-lang/rust#63010) and failed the windows-2022 CI job. Fall back to the file's mtime in nanoseconds on non-unix instead of pulling in an unstable API for a tier-2 platform.
The non-unix identity fallback (mtime) can't distinguish two files created within the same CI-runner tick, which is what the test does deliberately to force the race. That's a real limit of the tier-2 fallback, not a bug the test should assert against on windows.
…ssel switch RebuildCameraList only ever ran from onVesselChange, so docking two vessels never revealed the joined craft's cameras until an unrelated later vessel switch happened to fire - confirmed live (kerbcast#2 follow-up): a dock at 12:36:54 with no accompanying switch stayed at the pre-dock camera count, while a dock immediately followed by a switch correctly showed all cameras. RebuildCameraList now takes a disposeMissing flag. onVesselChange keeps the existing full dispose+rebuild (scope the list to whichever vessel you're flying). onVesselWasModified - which fires on docking/staging without a pilot switch - now also calls it, but additively only: skip already-tracked flight IDs, never dispose. This picks up a docking partner's cameras immediately, without tearing down staged-off debris cameras that should only stop streaming when they actually leave physics range.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
onVesselChange(e.g. a booster surviving separation, or a docking-port camera reused across dock/undock) could be deleted and recreated at the sameflight_idwithin one tick, with nodestroyedtombstone. The sidecar's rescan only reattached rings for tombstoned entries, so the mmap stayed pointed at the unlinked file forever — no browser refresh could recover it.rescan()now tracks each ring's filesystem identity and reattaches whenever it changes, reusing the existing attach-driven peer resync path.RebuildCameraListnow takes adisposeMissingflag —onVesselChangekeeps full dispose+rebuild (scope to whichever vessel you're flying),onVesselWasModified(docking/staging without a pilot switch) now also calls it additively, picking up a docking partner's cameras immediately without tearing down staged-off debris cameras that should persist until they leave physics range.docs/TROUBLESHOOTING.md's "Still stuck?" section into a reusable log-collection checklist.Test plan
cargo test(96 tests, including a new regression test reproducing the ring-recreate race) +cargo clippy --all-targetsclean on linux/windows/macOS CIring file identity changed... reattaching/re-attached camera rebound to surviving peer subscriptions) and camera counts are correct in all traced cases